嗨！一年一度的鐵人賽又來了，我在前年跟去年參加了兩次鐵人賽，都是前端技術為主的討論:
其實每一年的參賽，多少都標誌著我自己的成長軌跡。
從第一年懵懵懂懂，JavaScript 想要學得更好；
到第二年，已經有了些許經驗，爬到更高的山頭，用更寬廣的角度俯瞰自己學的這些工具。
接著今年是第三年了，如果按照前兩年這個線性成長的趨勢，好像應該來寫個什麼:
「前端架構設計的 30 堂課」
「前後通吃，全端工程師的生存法則」
結果今年因為公司內一些人事異動，工程腳步都還沒踩穩的我，突然就有機會成為管理職，接觸管理技能了！
所以，今年決定跳離原本的賽道，報名 IT 管理的組別，來寫個菜鳥主管主題！
以前做為 RD 這樣的職位其實相對單純，基本上工作項目就是「用 code 來解決問題」。
但在我成為管理職，並開始接觸一些管理的書、朋友，以及實際的管理經驗之後發現，管理的環境與 context 是非常重要的：
以上都會影響到管理時要用怎樣的策略，如何與成員應對進退，甚至管理者本身的工作項目都可能因此完全不一樣。
比如團隊成員數量少，只有 2~3 隻貓，因為人少，所以只要建立起信任與默契，就能夠很好發揮團隊的工作效率(溝通成本低)，這時管理者的重點會著重在，如何善用每個人的長處，適才適所，並且能夠與團隊成員建立比較深的連結。
但當團隊成員到了 20~30 個，甚至更多時，幾乎很難每個成員都三不五時來個 1 on 1 ，這時就會傾向抓大放小，建立能夠讓大家順利工作的流程與機制，嘗試跟上級斡旋更多資源，也通常會需要「訓練出好幾個自己」，讓小主管學著去帶人，才不會把自己累死。
因此，往下閱讀系列文之前，希望大家先看一下我公司目前的情境，比較能夠同理我遇到的難題XD
我在一間五歲的(老)新創本土公司，主力產品是做長照科技的 SaaS，因為產品的面向主要是長照/日照機構的護理師與管理者，所以是以 B2B 的模式為主，全間公司約有 100 多位的員工。
而我所在的部門就是公司目前核心產品的 RD team，雖然是目前主要在賺錢 &燒錢 的 team，但因為台灣的長照市場就是這樣而已，所以目前這個核心部門還是以維護既有客戶，針對需求開發為主要任務，沒有太多拓荒與空降的部分，自然也不會投入大量資金或人力進來，處於一個「能用就好」的狀態。
團隊中的 RD 有 7 位(不含我)，基本上在較簡單的需求開發時，每一位都是寫全端(React + Nodejs)，只有比較需要開發共用元件、底層架構時，才會細分前端/後端/雲端(?)專長。
成員的部分就不細節介紹了，不然文章還沒寫完如果離職怎麼辦XD，但平均來說寫 code 經驗落在 3 年左右，程度算是偏 middle 一點，除了其中一位是比我還資深的 senior RD。
這次系列文的重點在於「管理」與「難題」，前者很好理解，就是關於工程師「轉職」成主管職，過程中心態上的變化，管理思維的調整。
而後者「難題」代表的是「我也沒有標準答案」
我想這是跟前兩年系列文很大的差異，之前寫技術文，經常能夠去對應問題與解法：
遇到需要前端全域管理狀態的情境，解答八成是拿 Redux 相關的工具來用。如果上 stackoverflow 去問這種問題，會拿到的答案都相差不遠。
但我想管理就不是這回事，管理要考量的情境複雜得多，往往不是一點點上下文就能推出正確答案，甚至可能是「沒有正確答案的」：
同樣一個「如何幫團隊成員考評」，問 10 個人會有 11 個答案。
我想這是管理有趣的地方，因為嘗試不同策略會有意想不到的效果，但也是讓工程師難受的地方，因為就算使用同一個策略，在不同的團隊也可能有截然不同的效果。
因此我將系列文定調為「難題」與「策略」：
希望是盡可能涵蓋多一點範圍，如果有漏的話，也拜託讀者一起來討論囉！
參加鐵人賽的過程，就跟在跑馬拉松一樣，剛開始時，體力充足，靈感充沛，覺得一定沒問題！
但可能連一半都還沒到，就慢慢感到腳步疲軟，注意渙散，然後開始怨念:
到底當初為什麼要參賽...
但愈是接近終點就愈會發現，明明很疲憊，卻充滿精力；明明想放棄，卻找不到放棄的理由，於是閉上眼，下一次眼睛睜開，終點就到了！
所以。。。我要開始閉眼囉！大家 30 天後見！
iThome鐵人賽
看影片追技術